Towards a Method Framework for Enterprise Architecture Management – A Literature Analysis from a Viable System Perspective

The discipline of enterprise architecture (EA) management is albeit a long history still developing. This is becomes obvious, when literature on the EA management function is analyzed. Multiple approaches describe different make-ups for the overall function, while a common sense does yet not exist. In this paper, we analyze EA management functions as proposed in literature from a systemic perspective and derive typical management activities such a function should encompass. Based on these activities, a method framework for EA management is derived, which is assessed in a case study from the financial industry. 1 Motivation and overview Enterprise architecture (EA) management is a discipline, which has recently gained increased attention from academia and practitioners. Thereby, a few topics which are nowadays regarded to be part of EA management, have a long history in information systems research. This can be exemplified with the topic of business-IT-alignment, which has been discussed e.g. by Henderson and Venkatraman in the late nineties as strategic alignment [1]. While these discussions might have catalyzed the evolution of EA management, the overall discipline is still subject to ongoing development. This in particular applies as different research communities continue to argue on the perspective, from which EA management should be approached. Some researchers emphasize on business aspects, advocating for an understanding of EA management as an economic management discipline (cf. Frank in [2]). In contrast, other groups point to the engineering aspects (cf. Aier et al. in [3]) or take a systemic perspective on the topic (cf. Buckl et al. in [4] and Wegmann in [5]). The approaches nevertheless agree that EA management needs to provide a holistic view on an enterprise, accounting for aspects from all layers, ranging from business to IT aspects. Regardless of the question of perspective, other indications for the ongoing development of the EA management discipline exist. A prominent example for this is the topic of EA modeling. Although most EA management approaches emphasize on the importance of modeling the EA, no common metamodel (called information model in accordance with Buckl et al. in [6]) has yet been established. In the last years, many information models were proposed but none of them has yet gained broad acceptance. Some researchers even challenge the hypothesis that such a model exists (cf. Buckl et al. in [7] and Kurpjuweit and Winter in [8]). They expect enterprises to have largely different expectations on the benefits of EA management, and therefore assume that an information model is an enterprise-specific artifact. Similar discussions apply to the overall make-up of the EA management function. Many different activities have been argued to be inseparable parts of EA management (see Section 3). In contrast, approaches presenting constituents of the EA management function or comprehensive processes descriptions are rare in academic literature (for one example cf. Hafner and Winter in [9]). Similarly, few practitioners (cf. Niemann in [10] and Schekkerman in [11]) and standardization bodies (cf. The Open Group in [12]) discuss processes but stay on a fairly abstract level. These processes are usually complemented with a remark that ”they have to be adapted to the company’s needs”[12], while the details of this adaptation are left to the reader. We expect the EA management function, similar to the information model, to be enterprise-specific, although – on a more abstract level – every EA management function might be comprised of similar activities. Thereby, we must provide additional clarification in respect to the understanding of the term EA in different research communities. While some researchers refer to the term EA as the management function, aiming at managing the evolution of the EA, others regard the EA as the inevitable fact, which refers to the make-up of the enterprise summarized as ”every system has an architecture”[13]. The terminology used in this paper adopts the later wording and clearly distinguishes between the artifact (EA) and the corresponding management function (EA management). The article presents a first step towards establishing a consolidated method framework for EA management, which can be configured according to the enterprise-specific needs of a company. The framed method is grounded in a systemic perspective on EA management, which is exhibited in Section 2. From this perspective, Section 3 revisits prominent approaches to EA management from literature and collects typical work packages that these approaches propose. In addition, the representations of the EA, the so called EA descriptions, are analyzed. With the activities and the descriptions at hand, Section 4 proposes a method framework for EA management, consisting of four main activities of an EA management function and three different types of EA descriptions. The framework further describes how the activities relate to each other, and specifies which descriptive information about the EA is exchanged between them. In this respect, it can be regarded as abstract method framework for the EA management function, providing the answers to the article’s research questions: – Which typical activities constitute an EA management function? – Which information objects are created by, exchanged between, and used for these activities? – How do the activities relate in a method framework for EA management? Section 5 sketches the results of a case study on the EA management function of a company in the financial industry. We thereby show to which extent the method framework can be validated. The article concludes with Section 6, which summarizes the findings, shows limitations of the research approach chosen, and gives indications of future areas for research. 2 EA management from a systemic perspective Enterprises form highly complex systems consisting of various different elements interlinked by a large number of interdependencies. These systems are further embedded into a changing environment that they continuously have to adapt to. In particular, market changes and new legal requirements force enterprises to adjust their architectures, e.g. to rework their business processes or to evolve their IT artifacts. Additionally, newly emerging technologies may enable new business opportunities that an enterprise should proactively seek to gain competitive advantage (Ross et al. in [14] and Wagter et al. in [15]). Both the reactive and the proactive change of the enterprise fall into the responsibility of enterpriselevel management functions, as application or project portfolio management, but also of the EA management function. In this respect, the different management functions on the one hand and the EA management function on the other hand form an interacting system. Understanding this system of systems is a necessary prerequisite for developing a method framework for EA management. The viable system model (VSM) (Beer in [16, 17, 18]) provides a framework for describing complex management systems from a systemic perspective. In the following, we discuss the five subsystems of the VSM – operation, coordination, control, planning, and identity – and identify these subsystems with constituents from the EA management system. – The enterprise-level management functions form system one (operation) directly changing the EA via projects. Especially the management functions surrounding the project lifecycle contribute to system one. Exemplary functions are: enterprise-wide demand management, where demands are captured and prioritized; strategies and goals management, where demands and projects are aligned with the enterprise’s goals; synchronization management, where project dependencies are monitored (cf. Wittenburg et al. in [19]). – The communication function of EA management forms system two (coordination) by which architecture descriptions are distributed via appropriate communication channels. Thereby, the different enterprise-level management functions (cf. Wittenburg et al. in [19]) are provided a shared understanding of the as-is (current) and the to-be (planned) state of the EA. Based on his shared understanding peer-level coordination between the enterprise-level management functions should be fostered. – System three (control) forms the reactive function of EA management, that establishes higher level control over the coordination function. In particular, the reactive EA management observes the behavior of the enterprise-level management functions in coordination and assures that no ’oscillatory’ effects between these functions develop. This would for instance be the case, if projects would adapt to comply with current architectural standards for business applications, while simultaneously the standards were adapted to incorporate the realities of the new application portfolio. – Where system three ensures stability in the interactions of the enterprise-level management processes, EA management also encompasses a proactive function in system four (planning). Latter system is responsible for anticipating changes in the environment of the enterprise and for addressing these changes by altering the status-quo that is maintained by the underlying homeostatic control in system three. – Completing, system five (identity) is responsible for EA management governance, i.e. is concerned with questions of the overall scope and reach of EA management. It further shapes the design of the EA management function itself. Thereby, it ensures a balance between short-term and long-term efforts, and steers the EA management system as a whole. 3 State-of-the-art in EA management literature This section provides an overview about selected EA management approaches from a viable system perspective as introduced above. Thereby, we focus on activities described as being part of the EA management function and detail on the EA descriptions they expect for input or provide as output. In the description of the approaches, the original terms employed by the authors are used. One of the most prominent frameworks for EA management is proposed by The Open Group – The Open Group Architecture Framework (TOGAF) ([12]). The core contribution of TOGAF in respect to describing the EA management function is the Architecture Development Method (ADM), which delineates how an EA can be developed and maintained. The ADM describes EA management as an iterative and stepwise process consisting of different phases. The initialization of one EA management cycle is performed in the preliminary phase, where decisions about the scope and reach of the management endeavor are made (system 5). Thereby, the topic how to link EA management to other enterprise-level management functions is decided upon. The following four phases architecture vision, business [architecture], information systems [architecture], and technology architecture are concerned with the development of a target state, the investigation of the current state, and gap analyses comparing these states. From a viable system perspective these phases present the reactive and proactive EA management. The transition planning from the status quo to the desired target architecture is performed in phase opportunities and solutions and decided upon in phase migration planning. The execution of the transformation is monitored in the implementation and governance phase. Finally, the overall performance of the management process is measured and assessed in the phase architecture change management, which therefore deals with aspects of EA management governance. The aforementioned phases are continually adapted to the needs and concerns of the stakeholders in an activity, called requirements management. TOGAF complements the description of the activities with elaborations on the input and output artifacts of each phase – namely visualization artifacts, e.g. a solution concept diagram or a business interaction matrix, as well as textual documentations, e.g. reports or catalogs. The aforementioned EA descriptions together with the stakeholder management, which a dedicated chapter of TOGAF emphasizes on, contribute to the communication task of EA management. A characteristic of the TOGAF framework is that each iteration of the ADM cycle is project-driven, which on the one hand guarantees the sponsorship for the EA management initiative, but on the other hand makes it hard to ensure the continuity of the outcomes. A consequence of this approach is the absence of an activity, which keeps the EA documentation up to date. Similar to the TOGAF ADM, Schekkerman [11] describes EA management as an iterative and stepwise process. Each iteration starts with the development of the EA vision (phase 1), which defines the environment, business drivers, and guiding principles. In addition, the scope and context (phase 2) as well as the goals, objectives, and requirements (phase 3) of the EA management endeavor are defined. Subsequent phase 4 derives different opportunities and solutions from existing documentations of the current state and future architecture plans. Thereby, special attention is paid to support decision making during management via adequate visualizations, models, and reports, which are chosen in this phase. Based on the opportunities identified in the preceding phase, different evolution scenarios are developed and evaluated regarding their organizational impact (phase 5). The costs and benefits of the scenarios are analyzed via business case calculations (phase 6) to support funding of the EA management endeavor. The results of the preceding phases are used in phase 7 to set up a scheduled transformation plan, including capability planning for the EA. Finally, a governance structure is implemented (phase 8), which defines the responsibilities as well as roles, groups, and committees needed. The EA descriptions developed in and exchanged between the phases are only briefly alluded to. Further, viewpoints used in the different phases of the EA management process are only discussed with regards to content without providing graphical representation. Furthermore, EA management governance is not presented as being part of the EA management function, although the importance of EA management maturity is discussed and a model to assess the maturity is presented. Niemann also emphasizes on the iterative and stepwise nature of EA management incorporated in the corresponding management ”cycle”, that consists of four phases – document, analyze, plan, and act – and a parallel check phase [10]. The document phase is concerned with gathering and maintaining information about the current state of the EA. The architects have to decide on the adequate level of detail of the documentation and define the appropriate EA descriptions to populate the model as part of the communication system of EA management. For the latter case Niemann further proposes different kinds of visualizations in [10], which can be used to document parts of or provide an overview over the EA. Although the approach elaborates on questions regarding what should be documented, it does not detail on the question how this information should be gathered and maintained. Based on the documentation an analysis of the current state of the EA is performed in order to identify potentials for improvement and optimization (reactive EA management). Niemann presents different areas for analysis, e.g. dependencies, heterogeneity, complexity, or conformity and provides methods as well as appropriate visualizations to perform the analysis. During the plan phase integrated development plans leveraging identified potentials for improvement and optimization are established. They represent planned states of the EA that are further assessed regarding their impact on e.g. business and IT goals, costs, and risks. The assessment should result in the selection of the optimal development plan in respect to the criteria devised before. This plan is realized in the act phase. Therefore, on the one hand reference architectures and blueprints are developed and implemented. On the other hand the required governance structures and processes are set up, e.g. the role and responsibilities of the enterprise architect are refined. In respect to the viable systems perspective a focal point in the approach lies on the reactive system of EA management. The EA management governance system is presented in the check phase, in which the performance of the previously described phases is measured and controlled. Thereby, key performance indicators (KPIs) are defined to analyze the overall performance of the EA management endeavor. Hafner and Winter present a consolidated process model for enterprise application architecture management in [9]. Although the paper restricts itself to enterprise application management, the approach is discussed here, as the presented process model is designed with the goal of effective and efficient businessIT-alignment, and therefore takes an EA perspective. The process model contains the phases architecture planning, architecture development, architecture communication, and architecture lobbying. The architecture planning phase is concerned with the documentation of current states of the EA. Thus, also EA principles are identified, derived, and updated, which guide the evolution of the EA. The proactive and reactive aspects of EA management are reflected in the architecture development phase, in which strategic and operational requirements regarding the EA are continuously recorded, consolidated, and prioritized. Subsequently, these requirements are incorporated in planned states of the EA. The phases architecture communication and architecture lobbying explicitly refer to the communication function of EA management. Nevertheless, aspects on how to relate the EA management endeavor to existing enterprise-level management processes are only briefly alluded to. More precisely, Winter and Hafner in [9] resort their approach to identifying target groups for training, information delivery, etc. While the task of analyzing the EA is made explicit as part of the consolidated process model, the assessment and improvement of the EA management approach itself (EA management governance) is not discussed. Another prominent approach in the field of EA management is the systemic enterprise architecture methodology (SEAM) [5]. The methodology defines the role of EA management as to federate the efforts of the specialists [from the enterprise-level processes] to ensure successful projects. This point-of-view interprets EA management as the glue between the different processes, i.e. bringing together information in this multi-disciplinary environment, thereby especially emphasizing on the communication function. The federation of efforts is achieved via enterprise models, which form means of analysis and communication of EA relevant information. These models account for the multi-disciplinarity of the environment, but go beyond specific models for each discipline, e.g. process chains or network topology models. They provide an integrated view on the enterprise. In [20], Le and Wegmann 2005 highlight two additional aspects of EA management: firstly, the reactive aspect, which deals with necessary business and technology changes ex post; secondly, the proactive aspect, which anticipates future changes of that kind and prepares the enterprise to them by increasing agility and flexibility. In contrast SEAM abstains from discussing questions of how to establish and govern the EA management process. In addition to the aforementioned approaches, which claim to define their own EA management function, various approaches exist that focus on selected topics in the context of EA management. Lankhorst et al., for example, detail on the topics of EA communication, documentation, and analysis in [21]. Therefore, a specialized modeling language is introduced, which fosters the communication between business and IT stakeholders, and can also be used for documenting current, planned, and target states of the EA. As means for decision-support, different kind of analysis techniques, including analtytical and simulation techniques are discussed. Thus, the approach focuses on aspects of reactive and proactive EA management in the sense of a viable system perspective, while the aspect of the communication system is discussed as a side-effect of the proposed modeling. Similar considerations hold for the approach of multi-perspective enterprise modelling (MEMO) presented by Frank [2]. The approach focuses on the activity of EA modeling by providing special purpose languages for different parts of the EA, e.g. the IT modelling language (ITML) [22] – for modeling IT related aspects – or for different activities performed in the context of EA management, e.g. the ScoreML [23] – contributing to the field of analyzing EAs. Although, the EA management function is not in the focus of the approach of Frank, he contributes to the field of reactive and proactive EA management in the terms of our viable system perspective. 4 A method framework for EA management Based on the above discussions of the EA management function and special purpose approaches for dedicated EA management activities, we devise a method framework for EA management. Central to our framework is the understanding of the three different architectural states – current, planned, and target – that can be found throughout the approaches discussed in Section 3. Table 1 revisits the state-of-the-art in EA management with a focus on EA descriptions. [2] [5] [9] [21] [10] [11] [12] target state # H# H# #